Portal for viewing data from integrated medical software system

ABSTRACT

A medical management system is provided that integrates all aspects of healthcare provider practice management and managed care, including schedule management, patient registration, insurance information, EMR and billing and collections. The system integrates a central framework module, a scheduling module, a registration module, an account management module and an electronic record module to provide a seamless exchange of information. A clinical module provides template builder which allows the users to define a customized template. The custom and standard templates are used by a document builder to generate documents, such as progress notes and H&amp;P notes, which are retained in the patient&#39;s electronic chart. The progress note template allows the clinician to record a patient encounter by presenting the clinician with predefined sections and sentences that are easily completed by the clinician during or after the patient encounter. The templates and documents generated are designed to closely resemble a paper chart. Information gathered during patient scheduling and triage are referenced to pre-populate the templates to avoid having the clinician entering redundant information. The documents are relied upon to automatically generate patient superbills and electronic requests are sent to a claims clearinghouse.

RELATED APPLICATIONS

The present application is a continuation of co-pending U.S. patentapplication Ser. No. 10/202,627, filed Jul. 25, 2002, which claimspriority to Provisional Application Ser. No. 60/373,662, filed Apr. 19,2002, the entire contents of which are incorporated herein by reference.

BACKGROUND OF THE INVENTION

Service professionals that regularly schedule patient visits havehistorically relied upon manual practice management, patient records andmanaged care (i.e., insurance) techniques. For instance, schedulingpatients, tracking prescription orders, and maintaining filedocumentation are typically performed through paper calendars and files.An office assistant receives and schedules patient appointments on thepaper calendar. The service professional then checks the paper schedulefor each day.

For purposes of this application, service professionals may include, forinstance, healthcare providers such as physicians (MD or DO), dentists,chiropractors, psychologists, and counselors. However, the terms“clinician” or “physician” as used herein are understood to include anyservice professional or healthcare provider who treats a patient,including for instance physicians, nurses, technicians, therapists,chiropractors, physicians assistant, midwife, psychologists, andcounselors.

All information concerning the patient's medical history, such asclinician observations, thoughts, treatments administered, patienthistory, medication lists, vaccine administration lists, laboratoryreports, X-rays, charts, progress notes, consultation reports, hospitalreports, correspondence and test results, have traditionally been keptin the paper file. Much of this information is handwritten and signed bythe clinician, or transcribed from clinician dictation. Paper-basedmedical files are typically filed alphabetically by the patient's lastname, with the patient's name, date of birth and any known allergies onthe outside of the file.

However, manual practice management, patient record and managed caretechniques are inefficient since they require a great deal ofinteraction between the service professional and the office assistant.Last minute scheduling changes often result in lost time for the serviceprofessional. In addition, manual tracking is prone to error and thelarge amounts of paper that is generated take up valuable office space.A small office of 2-3 physicians, for instance, can have approximately20,000 or more active patients, and therefore anywhere from about 25,000to 60,000 patient files, depending upon how long they have been inpractice.

Since the medical record is paper-based and manually produced, theinformation needed to bill a patient must be manually entered into thebilling application. Clinician orders that often generate billableprocedures are difficult to process because they are written by hand andin many cases are omitted from the patient's bill. In addition,handwritten orders for prescriptions have been identified as the numberone cause of medical errors resulting in patient death in the UnitedStates. Add to these issues the complexity of insurance contracts andprocedure fee schedules that govern the amount which clinicians are tobe paid for their services, and the result is a very inefficient,labor-intensive process requiring many checks and balances to ensureaccurate processing.

In a typical office visit for a medical clinician, the clinician willreview his/her schedule for that day or week. In any given day, theclinician may have 20-80 office visits, and up to 2 (or more) medicalprocedures. Prior to a scheduled examination, the clinician willmanually flip through the paper file, which has been retrieved from thecentral files by the office assistant, to determine the purpose of theoffice visit and review the patient's relevant medical history.

A typical patient visit or patient encounter takes about 10 minutes,with the physical examination comprising about 2 to 5 minutes. Followingthe examination, or sometimes during, the clinician will make progressnotes about the patient's medical condition, order any necessary tests,give the patient any prescriptions, and advise if follow-up appointmentsare needed. A clinician will usually spend about 2 to 5 minutes to makeprogress notes and place them in the patient file.

If tests are performed onsite, the clinician, laboratory technician ornurse, conducts the test. If the test results can be obtained relativelyquickly, the clinician might wait for the results before releasing thepatient, and review the results with the patient. Some testing, however,may be conducted off-site, and later reported to the clinician. The testresults must then be analyzed and reported to the patient after theinitial office visit, and follow-up appointments may be scheduled.

The amount of paperwork required has a significant impact on the serviceprofessional, which often detracts from the amount of time the serviceprovider can spend with the patient. In the medical arena, every hour ofemergency department patient care requires an hour of paperwork. Forsurgery and inpatient acute care, every hour of patient care results in36 minutes of paperwork. In skilled nursing care, every hour of patientcare results in 30 minutes of paperwork. And, in home health care, everyhour of patient care results in 48 minutes of paperwork. A physician canspend 22-38% of his/her time charting on paper.

In today's practice, service professionals, and physicians inparticular, have added restraints due to increased government andinsurance regulations, liability, working longer hours, less time tospend with patients, all of which result in the practice being lessprofitable and providing a lower quality of care. Governmental andinsurance rules and regulations include, for instance, electronicpayment requirements, HIPAA (Health Insurance Portability andAccountability Act) requirements (such as electronic health transactionstandards, unique identifiers, privacy and confidentiality standards,and security and electronic signature standards), coding and auditrequirements, restricted formularies, clinical pathways, increasedmalpractice risks from pseudo standards of care and requirements formore structured data.

Accordingly, there is a need for a system that can reduce the amount oftime spent by a clinician on activities outside the practice ofmedicine, such as paperwork, dictation, etc. There is also a need for asystem that can reduce the amount of time spent by other workers in theclinician's practice including the administrative or office assistants,nurses, clinician assistant, and laboratory technicians. Those systemsmust also be able to comply with government and insurance regulationsand must also provide data that can be analyzed to develop better careprotocols.

Systems have been developed which automate patient tracking, medicaldocuments or billing, such as described in U.S. Pat. Nos. 5,991,730,5,991,729, 5,946,659, 5,933,809, and 5,899,998 to Lubin et al., Barry etal., Lancelot et al., Hunt et al, and McGauley et al., respectively.However, automated systems have not been well received by the serviceprofessional community, with fewer than about 5% of all physicians usingsome sort of electronic medical record (EMR) system, which is broadlyunderstood to be a medical record system that has the capability toelectronically provide all of the functionality and features provided bythe paper chart, and data that can be analyzed to develop better careprotocols.

Service professionals have resisted those systems since they are unableto keep up with the rapid pace and movement of the service professionalduring the various tasks which are performed throughout the day. Onedisadvantage of those systems is that they are technology-driven, asopposed to being user-driven, and therefore difficult to use, especiallyby those service professionals that have difficulty with computertechnology.

In addition, those systems are fragmented in that they individuallyimplement a single activity of practice management and managed care tomanage scheduling, patient registration, insurance information, billingand collections. In instances where physicians are using EMR, practicemanagement and managed care applications to manage their practices, theapplications are typically stand-alone and run on disparate technologyplatforms.

The absence of a common technology platform requires multiple custominterfaces to connect the “silos” of information to work together inreal-time. The process of developing interfaces between disparateapplications by multiple vendors can be expensive and difficult and isusually costly and labor-intensive to maintain. Problems aretime-consuming and difficult to identify when they arise. These usuallycostly and labor intensive interfaces are typically used by largerclinician practice groups (50 or more), integrated delivery networks,and university-based practices.

Consequently, those prior systems do not provide a single system thatintegrates the features of practice management, patient records andmanaged care. Further adding to the problem, those systems are not setup to communicate with each other, so that practices that have more thanone system need to enter redundant information into each system. Thevarious systems are not well suited for interaction between each other,or to maintain information that would be useful to the other systems.

However, even if those fragmented systems could communicate with oneanother, the systems would merely be interfaced, as opposed to beingintegrated. Systems that are interfaced exchange limited data to addresspractice management, EMR and managed care needs. Interfacing systemsalso require multi-vendor support and the sharing of limited data acrosslimited system components and multiple databases. Interfacing also leadsto inconsistency in system user interfaces and system versioning isdifficult to manage.

SUMMARY OF THE INVENTION

Accordingly, it is an object of the invention to provide a medicalsoftware system that integrates all aspects of practice management andmanaged care, including schedule management, patient registration,insurance information, and billing and collections, with the EMR. It isanother object of the invention to provide a practice management systemthat is secure, has functionality and usability, tracks work flow forservice professionals, and makes the best use of manual resources. It isyet another object of the invention to provide a practice managementsystem that is cost effective to implement and maintain, even for smallpractice groups (2-5 clinicians), but is configurable to meet the needsof various specialties.

In accordance with these and other objectives, a medical managementsystem is provided that integrates all aspects of healthcare providerpractice management and managed care, including schedule management,patient registration, insurance information, and billing and collectionswith the EMR. The system integrates a central framework module, ascheduling module, a registration component, an account managementmodule, and clinical module to provide a seamless exchange ofinformation.

The clinical module provides an administration builder that allows usersto define a customized template. The templates are used by a documentbuilder to generate documents, such as progress notes and H&P Notes,which are retained in the patient's electronic chart. The progress notetemplate allows the clinician to record a patient encounter bypresenting the clinician with predefined sections and sentences that areeasily completed by the clinician during or after the patient encounter.The templates and documents generated are designed to closely resemble apaper chart. Information gathered during patient scheduling,registration, triage, and previous encounters are referenced topre-populate the templates to avoid having the clinician enteringredundant information. The documents are relied upon to automaticallygenerate charges, from which electronic requests are sent to a claimsclearinghouse.

The system results in increased revenue due to coding accuracy, billingand fee schedule cross referencing to reduce under-payments andover-payments, writeoffs, improved clinician productivity, improvedclaims management and payment reconciliation of under payments, patientcare reminders that generate preventive/preventative care visits, andimproved receivables collections. The system results in a reduction ofcost, such as a reduction in the cost of copying and storing documentsand records, malpractice insurance premiums, transcription costs, paperand related supplies, rejected claims and costs associated with claimsreprocessing, labor savings due to efficiencies and resulting inpossible staff reduction or redeployment, and decreased repeated labtests.

The system has intangible clinical advantages, such as improved qualityof patient care through the provision of preventive/preventative care,improved chart availability, drug/allergy interaction alerts, outcomesanalysis, improved response time for patient information requests,improved clinician and administrator satisfaction, reduction inpaperwork and increased available time to spend with patients.Intangible business benefits include more efficient scheduling andappointment notification, avoidance of misplaced or lost patient recordfiles, elimination of redundant data management, improved financialaccounting accuracy and reporting, and increased market share. Thesystem is efficient with respect to chart pulls, referral coordination,billing documentation compliance, coding compliance and lab reportfiling.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 shows the overall network architecture in accordance with thepreferred embodiment of the invention;

FIG. 2 shows the system architecture of the main services server 10 ofFIG. 1;

FIGS. 3 and 4 show the preferred architecture of the main servicesserver 10 and workstation 12, as having a client tier, business tier anddata tier;

FIG. 5 is a block diagram detailing the functional makeup of the system,with each module implementing the client, business (middle), and datatiers;

FIG. 6 is a block diagram of the AR module 30 of FIG. 5;

FIG. 7 is a block diagram of the clinical module 40 of FIG. 5;

FIG. 8 shows the visit information check-in screen and patientregistration information screen of the registration component of FIG. 5;

FIG. 9 shows the appointment scheduling screen of the scheduling moduleof FIG. 5;

FIG. 10 shows the desktop and internal messaging supported by theframework module 20 of FIG. 5;

FIG. 11 shows the facesheet screen of the clinical chart module 40 ofFIG. 7;

FIGS. 12, 13 and 14 show the account information, charges andcontracts/fee schedule screens of the AR module of FIG. 6;

FIG. 15 is a flow chart depicting the overall operation of the clinicalmodule 40;

FIG. 16 is the template administration screen of the clinical module 30;

FIGS. 17-27 show template administration screens used to define atemplate;

FIGS. 28-32 show the preview option during the template administration;

FIGS. 33-36 show document building screens used to build a document inaccordance with a template;

FIGS. 37-38 show a Progress Note document which was generated inaccordance with a Progress Note document building template;

FIG. 39 shows list of documents in a patient's chart; and,

FIG. 40 shows an H&P note being completed in accordance with an H&P Notedocument building template.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

In describing a preferred embodiment of the invention illustrated in thedrawings, specific terminology will be resorted to for the sake ofclarity. However, the invention is not intended to be limited to thespecific terms so selected, and it is to be understood that eachspecific term includes all technical equivalents that operate in similarmanner to accomplish a similar purpose.

The present invention delivers an ambulatory software suite thatintegrates practice management, electronic medical records (“EMR”)(i.e., patient records) and managed care functionality. An ambulatorysuite is a group of applications that is designed to meet all the needsof a practice. These applications are built on the same architecture andare designed to share information seamlessly based on integration ratherthan interfacing.

The system integrates, as opposed to interfacing, all aspects of aclinician's practice, namely the clinical, financial and administrativeprocesses. Integration provides a single vendor solution that addressesall practice management, EMR and managed care needs. It also allows forsingle vendor support and the sharing of all data across all systemcomponents through a single database which avoids errors, duplication ofdata entry and inconsistency of information. For instance, schedulingand registration data flows to billing; registration data flows to thepatient's chart; coding, scheduling and prescription data flows from thechart to billing, to the schedule and to the pharmacy, respectively.

A single integrated system also completes patient tracking whichfacilitates cost accounting analysis, provides consistency in all systemuser interfaces and allows for greater security and audit trails. Inaddition, system administration of all the applications can be handledthrough a single system administration feature. An integrated systemalso means only a single vendor, which eliminates the need for interfacemanagement, and that the system can be upgraded as a single entity withconsideration of all functionality that may be affected.

The EMR is characterized as having a direct data entry into a patient'srecord of all information that currently can be entered into a paperrecord. The EMR is a customizable and organized storage of information,and provides a comprehensive aggregation of content for a singleprovider or location for each patient. In addition, the EMR is capableof incorporating information from outside sources, such as throughdocument scanning, and has information mobility, accessibility andreviewability.

System Architecture

Turning to the drawings, FIG. 1 shows the overall system 5 in accordancewith the preferred embodiment of the invention. The system 5 has twoprimary elements: a main services server 10 and customer workstations12. Optionally, the main services server may be hosted at a data center(server 14) as opposed to being hosted at the practice location. Themain services server 10 is at the center of the system 5, and is locatedat a central location for communication with each of the customerworkstations 12.

The main services server 10 contains all of the system applications andcontrols operation of the system 5. The main services server 10 includesthe overall framework module 20 (FIG. 5), the AR (accounts receivable)module 30 (FIG. 6), the clinical module 40 (FIG. 7) and the schedulingmodule 23. The main services server 10 controls the communication of thesystem 5, stores data, and controls the various operations andprocesses.

The customer workstations 12 are located at various locations, remotefrom the main services server 10, throughout the clinician's office(s).The customer workstations 12 are part of a Local Area Network (“LAN”).The workstations 12 form the point of communication between the customerand the main services server 10. When the customer workstation 12 islocated at an office remote from the main services server 10, thecustomer workstation 12 preferably communicates with the main servicesserver 10 through a customer router which is accessed via a DSL(“Digital Subscriber Line”) network or frame relay network, and a siterouter. The site router is located with the customer workstation 12 andthe main services server 10 at the customer's location, and the customerrouters are located at a central location with an enhanced servicesserver 16.

When the main services server 10 is hosted at a designated data center,that hosted server 14 communicates with the customer workstation 12through a customer router, via the frame relay network or DSL network,and a data center core router. The enhanced services server 16 alsocontrols an Internet router used to provide access from the clinicianoffice to the Internet for email and web surfing capabilities. TheInternet router is located behind a firewall to provide security.

The system 5 has features addressing each of the HIPAA SecurityRegulation's requirements, including biometric login, restricted accessbased on login authorization (i.e., individual charts or chartsections), audit of who looked at what section of a chart and when, andthe restricted ability to copy, print, fax, email and export informationbased on login authority. The system also has functionality to assist incompliance with the HIPAA Privacy Regulations, such as consent trackingand disclosure logging functionalities. The system also supports EDIstandards, including transactions, code sets, and identifiers.

With respect to communications capabilities, HL7 (Health Level 7)compliant messages are fully supported and allow for inbound andoutbound data communications with most healthcare information systems.Thus, the system interfaces with other related systems, such as hospitalinformation systems, such as HBOC, Meditech, and Cerner. These hospitalinformation systems manage electronic data for hospitals and the systemexchanges information such as patient demographics, processingpre-certifications, orders, results. The system also interfaces withdiagnostic equipment lab systems to exchange information. Transactionalinformation and data associated with ADT (Admissions, Discharge, andTransfer), orders, results, labs, prescriptions and other data types canbe efficiently shared.

The system also handles non-HL7 messages for data exchange betweenclaims processors, diagnostic equipment and other medical informationsystems. All messages are designed with current industry standards andthe proposed/final HIPAA regulations in mind. Messaging requiring moreprogrammatic integration, as opposed to data exchange interfacing, canbe pursued through XML-based programming.

The system 5 preferably uses Microsoft's Digital Dashboard web-browserinterface, Microsoft Windows 2000, Microsoft SQL Server 2000 databaseand the Windows Distributed interNet Applications (DNA) technologies.The system's support for the HL7 data exchange standards and the X12N(Insurance Subcommittee of Accredited Standards Committee X12) EDI(Electronic Data Interchange) standards facilitate both systematic anddata-level integration, with X12 particularly supporting claimsprocessing and electronic remittance advice. Additionally, use of XML(Extensible Markup Language) provides for enhanced functionality withina browser environment and facilitates extensive interface configuration,such as with pharmacy or prescription systems, healthcare researchinformation, handheld devices and medical supplies ordering.

The system integrates the Unicor Alpha II coding database, the FirstDataBank drug interaction database and the SNOMED controlled medicalvocabulary database. These databases provide unique functionality andare provided as a “back-end” content repository which is maintained aspart of the overall system 5. The SNOMED medical vocabulary database isoptional, and need not be provided.

The customer workstation 12 is implemented in single technologyplatform—a browser, making use of a web-based, as opposed toweb-enabled, development approach. The browser facilitates remote accessto all practice and patient information within a highly securedenvironment, and enables communication between clinicians and theirpatients. The browser also enables a single source of support, tothereby minimize the cost of ongoing system maintenance. The browseralso enables a scalable solution that can be expanded from smallerclinician practices to larger healthcare communities, and can bedelivered to a targeted group of clinician specialties. The system alsoincludes a website that can be hosted as a service from an applicationservice provider, or deployed onsite at the clinician's office.

The system 5 employs a central service, which is a utility that runs inthe background and automates tasks. It uses an event driven design toperform tasks, wherein an event can be a file that is empty, have asingle line or a data file. The service monitors a set of directories onthe server and looks for the presence of an event or flag file toinitiate a script or application. The flag files indicate what action toperform. The central processor of main services server 10 manages thelaunching of script files to control operation. Multiple scripts andflags can be used together to complete tasks, and each task may consistof multiple scripts and/or third party programs. The central serviceuses two types of utilities, one that runs on the base and one that runson the main services server 10.

The clinician preferably uses a highly graphical and configurableinterface which is implemented with a stylus and lightweight, mobilepentop input device. The office administrator also interfaces with abrowser interface which enables rapid data entry and retrieval. All theuser interfaces communicate with the customer workstation 12.

The main services server 10 includes a data repository. The repositoryuses relational database technology to manage all discrete datacentrally, which facilitates the sharing of information across all areasof the system. This functionality reduces the potential for redundantdata entry and data storage.

The system network 5 allows clinicians to collect patient outcomeresults and correlate those results with treatment plans to measureeffectiveness. That information can be exchanged with data from otherclinicians, research institutes, universities and pharmaceuticalcompanies for broad-based ongoing research. Data is aggregated from eachparticipating clinician's clinical module into a centralized repositorythat is maintained by the enhanced services server 16, with appropriatede-identification performed to protect patient privacy. A controlledmedical vocabulary is enforced to normalize the collected data. Accessto the repository is controlled to certain biomedical informaticsresearchers, who can use query tools to mine the data.

The network 5 allows the clinician to submit claims directly through thenetwork to payors, eliminating clearinghouse costs and delays, orthrough a clearinghouse, taking advantage of clearinghouse edits andsupport. The network 5 can further be used to aggregate the purchasingof supplies, goods and services by clinicians and patients.

FIG. 2 shows the system architecture from an applications standpoint.FIG. 2 represents the internal workings of the main services server 10of FIG. 1. The services represent a series of Windows 2000 Serviceprograms that support and enhance the functionality of the MTS COM+middle-tier and to provide operating system capabilities to the productas a whole. SP (Stored Procedures) and Functions are two different waysof storing source code in the database. Processes can be supported ateither the IIS server or the COM+ server.

FIG. 3 shows the preferred architecture of the main services server 10and workstation 12, as having a client tier, business tier and datatier. Both the data tier and the business tier are located on the mainservices server 10 and the client tier is located on the customerworkstation 12. The architecture is based on Microsoft DistributedInternet Applications (“DNA”) architecture using COM+ middle-tierobjects for business rules and Microsoft Transaction Server (“MTS”)transactions for resilient database storage and retrieval. A standardn-tier design model provides separation of the detailed practicemanagement business rules from the data storage and client presentation.

The client tier targets Microsoft's Internet Explorer 6 as the clientplatform. The business tier is implemented on Microsoft Windows 2000server using the Microsoft Internet Information Server (“IIS”),Microsoft Active Server Page (“ASP”) technology, Microsoft TransactionServer (“MTS”), and COM+ middle-tier objects. The data tier makes use ofMicrosoft SQL*Server 2000. The IIS tier provides for handling therobust, interactive client needs of the product. The MTS COM+middle-tier provides for a centralization of business logic androutines. The SQL*Server Database tier focuses on data storage andaggregation. The IIS, COM+ and SQL*Server are also shown in FIG. 2.

FIG. 4 shows another preferred architecture of the main services server10 and workstation 12, as having a client tier, business tier and datatier. FIG. 4 makes use of all the benefits of FIG. 3, but extends themodel to make use of current Microsoft XML-based Internet architecturedesigns to provide an interactive client experience. A standard webInternet design model provides for tighter integration of thecustomization of business logic and the web browser presentation, whichis extended with Microsoft Internet technologies XML and VB scriptingclasses.

The client tier uses Microsoft Internet Explorer 6 as the clientplatform. The business tier is implemented on Microsoft's Windows 2000Server using IIS, ASP and native XML communication and handlingcapabilities. The data tier primarily stores data in XML files so thatdata, content and context can be stored together in a meaningful way. Italso makes use of Microsoft SQL*Server 2000 to provide for fast, easysystem access to list-driven data storage, using XML-SQL functionalityand enhanced functions capabilities.

The data tier in this model also makes use of the File System forstorage of clinical documents and user customizations. Using the FileSystem to store clinical documents improves the speed of the systembecause once a clinical document is signed, it is always referenced as aview-only document. The web architecture lends itself well to thetransfer of documents.

Main Services Server

An overview of the main services server 10 structure is shown in FIG. 5.The main services server 10 has a framework module 20 with variouscomponents 22, reference databases 26, scheduling module 23, AR module30 and clinical module 40. The clinical documentation of the EMR ishandled by the clinical module 40. FIG. 5 shows the functional makeup ofthe system. Each module has pieces of code implementing the client,business (middle), and data tiers. A majority of the EMR interaction isdone through robust client-side interaction with the customerworkstation 12, but is centrally processed, stored, and managed by themain server 10. The main services server 10 is also capable of receivingpatient demographic and financial information from legacy systems 24 byway of migration utilities that import that information into the mainservices server 10 database.

The main services server 10 communicates with a claims clearinghouse 28for processing insurance claims. The AR module 30 is shown in furtherdetail in FIG. 6 and the clinical module 40 is shown in further detailin FIG. 7. The main services server 10 has a centralized frameworkmodule 20 that supports communication between the various components 22,the scheduling module 23, the AR module 30, the clinical module 40 andthe legacy system and reference databases 24, 26.

A central database 25 is provided that is used to store data for each ofthe framework module 20, the various components 22, the schedulingmodule 23, AR module 30 and clinical module 40. As used herein, patientdata generally refers to demographic, financial and clinicalinformation. Clinical information includes symptom, observation,treatment, assessment, diagnostic and therapeutic information. Thecentral database 25 ensures that all information used by the system isretrieved and stored at the same location, to avoid users having toenter redundant information and ensure that all areas have access to themost current information.

The scheduling module 23, the AR module 30 and the clinical module 40are separate and distinct modules, but are fully integrated through theuse of shared functionality in the framework module 20, such as thedesktop, registration, reports, audit logging, security, system setup,user preferences, alerts and reminders, and messaging. The main servicesserver 10 provides seamless integration between the framework module 20,the scheduling module 23, the AR module 30 and the clinical module 40,as well as other ancillary components, including the central websiteportal, centralized messaging, email, and protected Internet access. Theframework module 20 preferably has components 22 which includeregistration, reports, system administration, communication, help,messaging and desktop.

FIG. 5 represents integration of each stage of a clinician's practice,including scheduling, registration, charting, AR management andreporting. The system automates each of the processes associated with aclinician's practice, from patient scheduling, to the clinicalencounter, though the process of filing claims and receiving payments.Information collected within one area of the system flows together tofacilitate a workflow process at another area of the system.

For instance, information is collected throughout the patientregistration, and is used by billing to initiate the coding and billingprocesses. The integrated system reduces the administrative burden,allowing more time to spend with patients, streamlining the claimsprocess and improving coding and the financial accuracy associated withthe billing process and ultimately maximizing the practiceprofitability.

On the financial end, the system integrates coding and billing, feeschedule management, patient statements, AR management, collectionselectronic remittance advice and reporting. AR management includes, forinstance, electronic charge tickets, balance tracking, charges, paymentsand adjustments, claims processing, claims maintenance, electronicremittance, contracts and fee schedules, insurance plans, andstatements. Coding and billing includes, for instance, automation tofacilitate coding and documentation compliance, as well as fee contractanalysis. This assists managers in their effort to eliminate theoccurrence of undercoding, reduce the risk associated with potentialovercoding and identify instances of under-payment to maximize profitsand reduce coding liability.

Thus, the system handles point-of-care charting, such as documentmanagement, point and click document generation, evaluation andmanagement (“E&M”) coding assistance, summary lists, prescriptionmanagement, orders and results and flowsheets. On the clinical side, thesystem integrates point of care charting, discrete data storage,clinical reminders, laboratories and prescriptions, documentationcompliance, coding assistance, order management and reporting.

On the administrative side, the system integrates patient scheduling,patient reminders and alerts, desktop, registration, insuranceeligibility, visit check-in and check-out, reporting, audit logging,security, system setup, user preferences, and messaging.

Registration

The framework module 20 of the main services server 10 has aregistration component 22 which includes visit check-in 33 to capturedemographic, insurance coverage and administrative information for eachpatient. The information in the registration component 22 can be enteredby the practice staff. However, the information can also be entered bythe patient through a secure Internet link or at a waiting room kioskthrough an interface with the customer workstation 12. Required fields,patient flags and checklist procedures ensure thorough informationcollection for new patients and prompt the user to ensure that theexisting patient information is kept current.

The registration component 22 supports patient registration, includingnew patient information and access to patient demographic informationfrom any prior management system which has been imported from a legacysystem 24. The registration component 22 stores any information obtainedfor new patients and information modified for existing patients,including both demographic and insurance coverage information.Registration usually takes place after the patient has scheduled anappointment, but the system will allow registration without a scheduledappointment, which is useful for physician practices that accept walk-inpatients.

The information retained by the registration component 22 can be used byany other component 22, as well as the scheduling module 23, the ARmodule 30 and the clinical module 40. Likewise, the other components 22,the scheduling module 23, the AR module 30 and the clinical module 40sometimes receive new or updated information that is then stored by theregistration component 22. In this manner, the main services server 10has a single source of registration information that is used systemwide,so that users need not enter information that has been previously storedat one module when working in another module. In addition, theregistration information is always kept current for all modules.

The registration component 22 can also receive patient data from a priormanagement system, e.g., a legacy system database 24. The information inthe legacy system database 24 is imported from a prior managementsystem, either through manual entry or by conversion of electronicinformation. The registration information imported from the legacysystem database 24 may include demographic information about thepatient, such as name, address, date of birth, social security number,insurance coverage, and sex. The legacy system database 24 may alsoinclude financial data, such as outstanding balance, accountinformation, and insurance claims being processed. The system 5 alsoallows for the import of financial information into the AR module via afinancial migration utility.

Visit-specific information, such as financial responsibility and thirdparty insurance coverage is also captured. The information is madeavailable to other components of the system, such as for charts andbilling to eliminate redundant data entry and management. The systemincludes patient identification and record retrieval by digital photo,which allows personal treatment of the patient as well as positiveidentification to prevent insurance fraud.

The desktop 22 displays the check-in and check-out status of patientsand supports unscheduled patients and can launch a patient's chart. Thesystem displays the present day schedule, as well as open visits fromprior days. If the user selects another date, the visits and scheduledappointments for that selected date are displayed.

The system registration allows users to associate one or more insuranceplans with an employer. Users may set up information about localemployers for association with patients and persons. This functionalitygreatly speeds up the process of entering insurance information for aspecific patient. Instead of entering detailed insurance information forevery patient, using this functionality, a user can quickly capture apatient's insurance information by associating a patient with a specificemployer insurance plan that has already been entered into the system.Thus, insurance plan maintenance or the addition of new plans can beperformed for a patient's record while accessing the patient'sregistration information.

In the example shown in FIG. 8, the user has entered all of a patient'sdemographic and insurance coverage information into the system,including all of the CMS (Centers for Medicare & MedicaidServices—formerly HCFA, the Health Care Financing Administration)required data, as well as other useful information such as e-mailaddress and the patient's digital photo. Once the patient information isentered, the user is ready to check the patient in. Additionally, fromthe visit check-in screen, the user can easily see important informationabout the patient, such as referral management information, paymentcollections notices and co-pay arrangements. The system automates theprior approval for referrals, admissions, orders, procedures, specialmedications, and other items requiring prior approval.

The visit information component 33 is primarily used to track apatient's office visit. In preparation for the visit, the visitinformation sub-section 34 obtains information from the schedulingmodule 23, namely Date of Service, Time of Service, providers, andlocation. That information is used to pre-populate the user's check-inscreen and the user can fill in any missing information.

The user may also input pre-certification information from the insurancecompany or from the patient at check-in, if that information has notbeen previously obtained and entered into the scheduling module 23 or ifthat information has changed since the patient made the appointment. Theuser also obtains information from the patient regarding the purpose forthe visit, if that information has not been previously obtained andentered into the scheduling module 23. The visit information, however,is not used to update the scheduling module 23, but rather any changesto the appointment information is retained for historical/trackingpurposes.

Scheduling

The scheduling module 23 supports scheduling for patients, clinicians,staff members, office equipment, or any resource the user chooses todefine. Scheduling is a rules-based, flexible module that supports manydifferent levels of scheduling complexity. Appointment scheduling isadministered using automated scheduling rules that ensure properresource and time allocation, and further facilitates a smooth flow ofpatient appointments. Appointment scheduling is configurable to thepractice and to the user. The user can review schedules at any time fromany point in the office, providing the office assistant with real-timeappointment availability information, and providing the clinician withreal-time scheduling information.

Users can schedule patient visits using simple “drag and drop”techniques in accordance with personnel, resource and equipmentavailability. It provides appointment reminders and alerts to minimizeerrors, allows for more efficient processing of appointments and ensuresthat patients are properly prepared for their visits. Patient flags,such as In Collections, Disabled Patient, and History of MissedAppointments, can be associated with a patient to serve as reminders tomake special arrangements for a specific patient when scheduling anappointment.

As an appointment is scheduled, all resources, such as facilities,equipment, personnel and medical procedures, are taken intoconsideration to ensure that conflicts do not occur between resources.Rules templates can be defined to control the available appointmenttimes for resources. Templates may be defined and applied across manyresources and dates to minimize schedule maintenance. The resources arepresented to the user with several viewing options, such as viewingmultiple providers' schedules on the same day or multiple days for oneprovider.

The user can perform advanced searches for multiple resources andvarious time and date ranges. Once search parameters have been definedand saved, the user may access the saved search template for future use.The next available appointments are quickly accessible and displayed tofacilitate an efficient scheduling process. The appointment schedulingreduces patient scheduling conflicts.

In the example shown in FIG. 9, the user has scheduled an appointment,and the system automatically alerts the user to remind the patient ofspecific instructions to follow prior to the appointment. Theinstructions are based upon the type of appointment that has beenscheduled for the patient. Additionally, as the user attempted toschedule the appointment, the system indicated that a rule existed forthat type of appointment, which the user then chose to view the rules.

Reports

The reports component 22 supports all reports. The system has a standardset of reports to meet user needs which users can display, filter andsort. Multiple filter and sort options can be saved as configuredreports for future reference. This standard report set with itscustomizing options allows users to report on almost any combination ofdata within the system database, which manages administrative, clinicaland financial patient data. The user selects the report criteria, suchas insurance company, insurance plan, billable provider, and the reportis generated.

In addition to the standard reports, a report writer allows the user tomodify and save existing standard reports. A user-defined reporting toolis provided which provides a number of pre-defined datasets which theuser can choose any fields from to create a customized report. Reportscan be run immediately, or in the background, sending a notice to theuser via the messaging system when the report is ready to view.

Reports can be generated as needed, as well as daily, weekly, monthly,or annually. Reports can be for any date or date range and can be sortedby many different parameters, such as provider, practice, insuranceplan, and patient. Once the report is generated, it can be printed, andexported to a variety of other file formats, such as Microsoft Word andExcel, for incorporation in office documents.

Examples of the standard reports include: Patient Financial, such asAccount Information Report; Demographic Information, such as PatientInformation Sheet; Provider Productivity Analysis, such as Summary ByProvider, Procedure Code Analysis Report, and Adjustment AnalysisReport; Practice Statistics, such as Procedure Code Analysis Report;Referral Information, such as Referring Provider Analysis Report;Scheduling Status, such as Appointment History Report, and DailyScheduling Report; Delinquent Accounts, such as Collection BalanceReport, and Aging Account Summary Report; Insurance Claims Reporting,such as Claims Analysis Report; Audit Report, such as Audit Log Report(HIPAA Security Requirement), and Disclosure Log Report (HIPAA PrivacyRequirement); Managed Care Reporting; Contract Analysis; DelinquentAccounts; Insurance Claims Reporting; and Accounting Reports, such asAccount Information Report, A/R Balancing Log Balance Tracking Report,and Transaction Detail Report.

Administration/Communication/Help/Reference Databases

The system administration component 22 supports all administrativefunctions, such as setting user passwords, system/user settings, andcontrolling access. Administration is implemented, for instance, at theAR administration component 31 of the AR module 30 (see FIG. 6).

The communication component 22 supports all the external communicationfor the system 5, including communication with the claims clearinghouses28. The help component 22 provides user support information for all themodules. The messaging component 22 controls internal messaging.

The reference databases 26 maintain all reference information that isneeded for the main services server 10. As shown in FIG. 5, thereference databases 26 include, for instance, postal information,insurance codes, drug information and a medical vocabulary such asSNOMED (Systematized Nomenclature of Medicine). The postal informationincludes information on zip code, city, state, county and country. Theinsurance codes stored in the reference database 26 include insurancerules and regulations, such as ICD (International Code of Diseases), CPT(Current Procedural Terminology), HCPCS (HCFA Common Procedure CodingSystem) codes, and CCI (Correct Coding Initiative) edits. The CCI editsdictate which CPT code combinations and which ICD-9 codes are valid tosupport certain CPT codes in order to be valid for payment of a Medicareclaim.

Desktop

Turning to FIG. 10, the desktop is shown, which is supported by thedesktop component 22 of the framework module 20. The desktop is the mainuser interface which allows centralized access to each component withinthe application. The desktop is presented to the user at a user inputdevice, which can be a wireless pentop or personal computer that is incommunication with the user's workstation 12. The desktop isconfigurable to the individual user's needs and preferences, to helpusers organize daily workflow and tasks. Users can view and filterscheduled patients and walk-in patients, and have access to internalmessaging and external applications such as stock quotes, web access andeducational resources.

A menu bar is located at the top of the desktop, with the options of ARmanagement, chart, registration, schedule and system. The menu bar has apull-down menu that allows the user to select the type of operations tobe performed. AR management is supported by the AR module 30 (FIG. 6).The user can check a patient's account information, charges, or e-chargeticket; or check payments and adjustments such as patient transactionsand insurance transactions; or check claims, such as claim maintenance,claim processing and claim status; or check system setup such as ARconfiguration, lookup tables, contracts/fee schedules, e-charge ticketconfiguration, insurance plans, procedures and statements.

If the user selects the chart option on the menu bar, the pull-down menuoffers the user the option of accessing patient charts, build templates,or administration of HPI, diagnosis plan, family medical history,genetic screening, past medical history, past surgical history, physicalexamination, ROS, social history and general template administration.The chart option is supported by the clinical module 40 (FIG. 7).

The registration menu bar option allows the user to access patientinformation, visit information and delivery information, and issupported by the registration component 22 of the services serverframework 20. The schedule menu bar option allows the user to accessappointment scheduling and schedule information, and is supported by thescheduling module 23 of the framework 20. The system menu bar optionallows the user to access report selection, security information such asgroup and user administration, and group rights, and system setupinformation such as care providers, communications, employers,locations, system configuration, system defaults and visit types. Thesystem option is supported by the report, communication and systemadministration components 22 of the framework 20.

The envelope icon at the top right of the desktop gives the user accessto the messaging center. If the icon shows a piece of mail (as in theembodiment of FIG. 10), the user has a new message. Clicking on the iconbrings the user to the message center. A key icon is located next to themessaging icon, and allows the user to change the user password. Thename of the user that is logged in is displayed to the right of the keyicon, which is Kathy in the present example. Clicking on the user's nameallows the user to log out.

A title bar is displayed beneath the menu bar. The title bar includes aflag icon, an information function and a search function. The presentday and date are displayed on the right-hand side of the title bar. Ifthe user clicks on the information button, a screen is displayed withinformation about the patient, including demographics, administrativeand financial data which is retrieved from the registration andadministration components 22 of the framework module 20. If the userupdates any of the patient information, the updated information isupdated at the registration component 22. The search button allows theuser to search for a patient, by name, ID number, or other patientinformation.

If the user has selected a patient, so that the patient is in thebuffer, the flag icon is activated in the title bar. The flag icon is anindicator of whether the currently selected patient has any flagschecked in the patient flags modal. If the flag is clicked, the patientflags modal is displayed, which indicates whether the patient has beenflagged for special attention.

Fields listed in the patient flags modal include: In Collections, NoInsurance, Wheelchair, Violent, Excess Balance, Expired Insurance,Canceled Appointments, Missed Appointments, Collection 1, Collection 2,Collection 3, Sensitive Chart, Do Not Call Home, Do Not Release Name, DoNot Mail to Home, Medicare Waiver Signature, Restricted Chart, SeeNotes. The user can select to add or remove flags for a patient, and thesystem can automatically create a flag, such as when the patient has anoutstanding balance on their account.

In the embodiment of FIG. 10, the user has configured the desktop toinclude a message from the messaging center, a listing of scheduledpatients appointments and checked-in patients. The user is creating amessage regarding medication refills. Once the user selects the patientname, the message is automatically pre-populated with information aboutthe patient which is retrieved from the registration component 22 of theframework module 20. The message can also be pre-populated with thepatient's chief complaint, and current medication information.

The listing of scheduled patients appointments can be configured by theuser, but generally includes the time of the appointment, the patientname, any scheduled resources, the type of appointment, and the chiefcomplaint. If the user wants to access patient information, the userselects a patient, which results in the patient name being displayed atthe top right-hand side of the title bar, which is Laura Barrows in ourexample. The check mark to the right of the selected patient is apull-down menu that displays a list of recently-selected patients. Ifthe user selects a patient from that list, that newly selected patientwill be the current patient in the buffer. The user can also selectpatients by selecting the search function from the title bar to searchfor the patient's name.

The system defines different types of users, such as clinical, researchand administrative, each having different user rights. The desktop onlydisplays those functions and information that are available for thatparticular user. For instance, the desktop would guide a clinical userinto the EMR portion of the system, and the administrative user into theAR practice management portion of the system.

AR Module 30

Returning to FIG. 6, the AR module 30 is shown in further detail, and isimplemented in accordance with the architecture shown in FIG. 3. The ARmodule 30 supports AR administration for a practice office. The ARmodule 30 summarizes patients' financial, medical and insuranceinformation to produce a financial record of the patient's visit used incollecting payment for the services rendered.

The AR module 30 includes AR administration 31, procedure/financialmapping 34, service detail entry 35, insurance claims 36, claimdetail/service detail history 37 and service details 38. The ARadministration component 31 supports administration of the officepractice, and communicates with the registration component 22, namelythe patient information 32 and visit information 33. For instance, theAR administration component 31 includes look-up tables and configurationinformation, fee schedules, contracts and insurance companies and plans.The information in the AR administration component 31 is preferably setup by the practice office administration to be specific to the practice.

The patient information sub-section 32 supports patient information,including access, retrieval and storing. If a user wishes to accesspatient information, the patient information component 32 communicateswith the registration component 22 of the framework module 20, whicheither stores the information or retrieves the information from adatabase. The patient information component 32 also retrieves insuranceinformation from the AR administration component 31.

The information retrieved from the registration component 22 and the ARadministration component 31 is presented to the user for display andmanipulation. For instance, the patient information component 32 maypre-populate a form being viewed by the user, such as an insurance formor progress note, with the patient demographics and/or insuranceinformation. Information that is new or updated from the patient isadded to the customer workstation 12 and sent to the registrationcomponent 22 and the scheduling module 23.

The procedure/financial mapping component 34 supports billing codes fromthe reference database 26, such as Unicor/Alpha II and CodeCorrect, aswell as charges, cost and time which are obtained from the ARadministration component 31. The mapping component 34 relates proceduresto the reason they were performed (diagnosis) and the charges, cost andtime for those procedures.

The service detail entry component 35 retrieves information from thevisit information component 33. That information is then used topre-populate the associated date of service, providers, locations, andinsurance plans for the service detail being entered. Information forthe service detail component 35 is entered either manually from anelectronic charge ticket or from a paper superbill, or can be enteredelectronically, such as by being electronically imported from theclinical module 40.

The paper superbill is essentially a charge ticket that is used duringcheckout and/or billing and is created in response to the clinician'sdiagnosis and orders. The electronic charge ticket is an electronicrepresentation of the paper superbill which may be used during checkoutand/or billing either manually or through an automatic import.

The service detail entry component 35 sends information to theUnicor/Alpha II reference database 26 for validation prior to claimcreation. Information from the service detail entry component 35 is usedto generate an insurance claim. The information is sorted and stored ina database according to insurance claims 36, the claim detail/servicedetail history 37 and/or the service details 38. The service detailentry component 35 communicates with the clearinghouse 28 to processinsurance claims, which responds to insurance claim requests with apass, fail or error.

FIG. 12 shows account information for a patient. As the documentationfor a patient visit is completed and authorized, all of the appropriatebilling codes may be automatically posted to the charge entry portion ofthe system. Coding assistance is available for ICD, CPT, and HCPCScodes, and warnings and alerts are based on the Medicare reimbursementguidelines to facilitate coding and billing compliance.

The system then references the respective insurance plans, contractsand/or fee schedules to locate and enter the appropriate charges intothe bill. Upon entry of the appropriate charges, a claim is generatedand available for automatic electronic transmission. As payments arereceived, the system allows users to post payments and immediatelyreconcile the payments to ensure that all accounts balance properly.

A sample of the charge posting is shown in FIG. 13. Charge postingconsolidates and prepares the coding data as it comes over from thevisit documentation captured within the system. Integrated coding editsenable the system to assist users in compliance with CMS and theNational Correct Coding Initiative. Warnings and alerts based on the CMSreimbursement guidelines are displayed prior to saving the information,and available for reference purposes.

Additionally, users can search for all applicable diagnosis andprocedure codes and arrange the format of a customized electronicsuperbill specific to the needs of the practice. When necessary,assignment of insurance coverage at the individual charge level issupported for tracking of charges within a single visit that areattached to different insurance coverage. Support for tracking multiplepre-certification numbers by insurance plan is included, and all patientdemographic and insurance information is accessible for real-time editsduring charge entry.

AR administration 31 also includes system parameters that allowaccounting and claims information to be processed in “real-time” forautomatic account posting and accurate reporting, or in “batch mode” forreview and editing purposes. Users can also set up the administrativeportion of the system to properly manage billing for multiple locationsusing a single Tax I.D.

Attachment of non-billable care providers to billable care providersallows more accurate revenue tracking. Users may establish multiplecharges and descriptions for single CPT or HCPCS codes with defaults tostreamline charge posting. Plan specific edits may be established toautomate conversions of data for specific claim generation requirements,such as type of service or modifiers.

Claims and statements may consist of single or multiple pages and areautomatically generated and available for electronic processing. Eachclaim that is created contains data for only one patient and for onlyone visit. After charges are grouped together by patient and by visit,they are then evaluated for multi-claim or multi-page separation. Oncethe claims have been created, they can be selected and edited prior toelectronic submission. The system supports multiple claim formatsincluding HCFA 1500, UB92 and ANSI XI2N 837 and NSF. Claim payments areautomatically posted and underpayment situations identified.

Claims management provides detailed filtering and sorting options thatallow users to work with claims by insurance plan, date created, datesubmitted, claim priority, claim payment status, etc. This functionalityprovides quick access to claims information, notes and actions, as wellas allowing users to view a claim in HCFA 1500 format.

Payment and adjustment posting retrieves the allowed amounts andcontractual adjustments from the appropriate fee schedule and posts themsimultaneously during payment entry. Additionally, applicablecontractual adjustments may be posted at the time of charge posting, orduring payment entry according to the respective insurance plan setup.Should insurance coverage change, the respective allowed amounts areautomatically recalculated. Credit management allows users to select acredit category for designation of payment overages or credits. Theutilization of these “credit buckets” reduces the efforts required forrefund processing and balance transfers by reducing the research neededfor processing credit balances.

Account information is quickly accessible for viewing, processing andediting purposes in summary and expanded line item displays. From theaccount line item view, all related transactions and notes can bedisplayed. Account information can be viewed in chronological order bydate of service, posting date or visit order. Additionally, robustfiltering and sorting options are available and can be saved forrepeated usage based on job function needs.

The system also generates collections letters, and performs tracking ofaged delinquent accounts and call tracking. Criteria can be defined sothat accounts and claims qualify for concentrated collection and followup activity by the office staff. Monitoring tools enable management totrack and evaluate collection efforts.

In addition, contracts and fee schedules can be set up and maintainedwith minimal effort, as shown in FIG. 14. Medicare part B fee schedulescome pre-loaded with the system and are annually updated, enabling usersto simply select the geographic region for their practice. The claimamounts are matched to the allowable amount of the contract toautomatically establish the correct allowed amounts for procedures. A/Rmanagement gives users several methods to establish a variety of feeschedules: percentage of charge, allowed amount, percentage of anotherfee schedule (including Medicare), etc., and to indicate which of thesefee schedules should be rounded and/or capitated. Contract fee schedulesare integrated into the system's charge posting and payment entryfunctions.

Clinical Module 40

FIG. 7 shows the details of the clinical module 40, which has a templateadministration builder 41, templates 42, 43, document builder 44 andvirtual file folders 45, 46, 47. The clinical module 40 supports theclinician's routines, from when the patient arrives at the practiceoffice, until the patient leaves. The clinical module 40 is implementedin accordance with the architecture shown in FIG. 4.

The general operation of the clinical module 40 is shown in FIG. 15. Thetemplate administration builder 41 is used to create templates 42, 43which are subsequently used to generate a document. Accordingly, at step52, the user defines a template using one of the available templateadministrations, such as HPI administration, ROS administration or PEadministration are first, then templates. Once the template 42, 43 isdefined at step 52, it can be used to create documents by the documentbuilder 44, step 54.

At step 54, the template builder 48 gathers information which, togetherwith prescription and medication lists and any imported documents, isused to build a document, step 56. The template builder can gatherinformation from the registration component 22, such as CC and/ordemographics, or information about history and habits that may have beenentered during triage or documentation of prior visits. The templatestructure ensures that a document can convert between XML and HTMLformats. The document is sorted and stored in a file system 45, 46, 47,in accordance with its document type.

The clinical module 40 supports the use of a triage note that promptsthe clinician to enter in detailed triage data for a patient. It isdesigned to be the initial documentation point in a patient's visit andwill usually be completed by a nurse before the patient starts theencounter with the clinician. All information entered in the triage notewill be used in other sections of the patient's visit as well as his orher patient record. The information available for entry includes Reasonfor Visit, Presenting Symptoms, Additional Notes, Vital Signs (BloodPressure, Heart Rate, Respiratory Rate, Temperature, etc.), Review ofSystems and Orthostatic Vital Signs. The Reason for Visit is updated inthe visit check-in information of the registration component 22 of theframework module 20, for use by other areas of the system.

The clinical module 40 supports the patient charts, or EMR. If the userselects Patient Charts from the Chart option of the Desktop menu bar(FIG. 10), the facesheet is displayed, as shown in FIG. 11. Thefacesheet of the currently selected patient chart is displayed when auser opens a patient chart. It contains critical but brief patientinformation most frequently used by the physician and nurse. It servesas a “homebase” allowing quick and easy access to more detailed parts ofthe chart. It allows the user to view and add vital clinical information(Vital Signs, problems, medications, Allergies etc.) at a glance withouthaving to navigate further into a patient's chart.

As shown, the facesheet preferably includes the patient's reason forvisit, vital signs, problem list, past medical history, medication list,and other pertinent information regarding the patient's medical history,which may have been entered during registration, scheduling or triage ofthe patient, or from a prior patient visit. The information displayedwithin the facesheet can be customized to show different informationlists. In FIG. 11, the clinician has chosen to add a new medication tothe patient's medical record. Also, the clinician has multiple patientrecords open, as shown by the multiple tab options listed across thebottom of the screen. The clinician can simultaneously see and rotateamongst multiple patients while also having immediate access to eachpatient's specific information.

The patient chart also allows the user to view summary information (asummary report), which includes, for instance, a listing of allergies,medications, family history, genetic screening, past medical history,past surgical history and any other user-defined information. TheDocumentation selection of the patient chart presents the user with alisting of all of the patient documents, such as Progress Notes, H&PNotes, Triage Notes and scanned documents. The documents can be amended,printed and cosigned.

The user can also move to any other area of the system from the patientcharts section, and can create a document, such as an H&P Note,Miscellaneous Note or Progress Note or Nursing Notes such as a TriageNote or Miscellaneous Note.

The clinical module 40 and the Desktop 22 support the followingoperations: indicating to the clinician that the patient encounter hasbegun by indicating that the patient has arrived and to retrieve thepatient from the waiting room; entering the patient's height, weight andvital signs; review and update or record the chief complaint, allergies,current medications, past medical, family and/or social history, presentillness, review of symptoms, miscellaneous notes; allows the clinicianto review previously entered information, including demographics andprogress notes; update any patient information in the system; record theresults of a physical examination, the clinician's assessment;automatically code the diagnosis (based on selections that were madeduring system setup and template building); record the clinician's plan;generate and document prescriptions and orders; record treatment; selectevaluation and management codes; generate a superbill for checkoutprocessing; and close the patient encounter.

The clinical module 40 forms the Electronic Medical Record (EMR), whichis comprised of all documents generated by the user for a patient,including facesheets (FIG. 11), Progress Notes (FIGS. 37-38) and H&PNotes (FIG. 40). The EMR provides an automated encounter documentationprocess and electronic patient record solution within an easy to useinterface that is both mobile and secure. Clinicians can electronicallyaccess and update all of their patient records within the practice whileseeing patients, and have remote access to patient records to assistclinicians while “on-call” or at the hospital.

Patient data can be entered in different formats, including scanneddocuments, dictation, transcribed electronic documents and throughinterface with third-party software and devices which capture results.The data is stored in the patient's electronic record. The EMReliminates redundant and illegible data in patient records, and focuseson quick, dynamic generation of accurate notes that adheres toregulatory guidelines.

Authorized users may access the same patient record simultaneously toreview patient medical history and vital signs, capture a patient'shistory of present illness, review of systems and physical exam,document an assessment and plan and have orders and prescriptionsautomatically generated for fulfillment by labs or pharmacies. Patientinformation can be displayed in multiple views and formats, such astext, form, table, flow sheet, or graphs, to facilitate rapid chartreview and determination of the context in which a patient's symptomsoccur.

As the clinician completes the encounter documentation, the appropriateICD, CPT and E&M codes are suggested and captured for automated billingpurposes. Thus, the EMR automates the entry of charges into the A/RManagement portion of the system for proper billing and claims filing,thereby reducing lost charges, ensuring that third-party reimbursementrequirements are met, and increasing revenue. The coding and billingprocess is initiated and any patient documentation is electronicallysigned.

Thus, the system eliminates the need for separate E&M coding for officevisits through the automatic calculation and suggestion of the E&Mcoding level based upon template-driven point-of-care documentation. Thesystem includes an integrated coding database which facilitates properdocumentation and improves reimbursement by enabling compliance withgovernment and insurance coding guidelines.

The patient record is the medical record for a single patient. Eachpatient's medical record contains instances of documents. The documentinstance is a single entry in a patient's record. Each document instanceadded to a patient's record has a date/time stamp and may be associatedwith a visit. It also has a document type associated with it, forexample a Progress Note, or a Triage Note, or a History & Physical. Thedocument type is used to sort and filter documents when viewing the listof documents in a patient's record.

Template Administration

Template administration permits the user to conduct administration tasksfor various document sections, such as ROS, PE, and HPI. The mainfunction of template administration is to create configured orcustomized templates, step 52 of FIG. 15. Templates are configurable bythe user, either by creating a template from scratch or by editing astandard or existing template.

An example of building a template is shown in FIGS. 16-32. At FIG. 16, atemplate administration screen is shown which permits the user tocreate, edit, or delete templates. The templates are organized infolders and displayed in a table. The user may add, rename, or removefolders and move files between folders.

The administration builder 41 is used to establish documentation choicesfor the chief complaint, HPI (history of present illness), ROS (reviewof symptoms), PE (physical examination) and assessment/plan. Theadministration builder component 41 is used to prepare templates 42, 43which assist the clinician in entering data into the system, which inturn are used to generate progress notes that are retained in thepatient's EMR. The templates are used to guide the user in building adocument, as reflected by the uni-directional arrows from the dataoptions of each of the templates should into the corresponding sectionsof the template document builder 48.

To build a custom template from scratch, the user selects to create thetemplate from the options displayed in FIG. 16, and identifies the typeof template to be built. If the user selects to create a procedure notetemplate, for instance, the system would exclude data categories for ROSand PE since those categories are not applicable to a procedure note.

Once the type of template is selected, the system guides the userthrough the process for creating the template. The system defines theappropriate sections for the template, such as Chief Complaint, HPI,ROS, PE and AP (assessment and plan). FIG. 17 shows the initial sectionto be defined by the user, Chief Complaint. The Chief Complaint is aconcise statement describing the patient's symptom, problem condition,diagnosis, physician recommended return or other factor that is thereason for the encounter. This field includes the chief complaintsidentified by the user to include in the template. The system allows theuser to define a default chief complaint and other possible complaints.The user can add additional chief complaints by clicking the “Addanother option” button or tabbing out of the textbox.

Once the user completes the CC section, the navigation button brings theuser to the History of Present Illness section template builder, asshown in FIG. 18. The History of Present Illness is a chronologicaldescription of the development of the patient's present illness from thefirst sign and/or symptoms or from the previous encounter to thepresent. It includes the following HCFA recommended elements: Location,Quality, Severity, Duration, Timing, Context, Modifying factors, andAssociated signs and symptoms.

The History of Present Illness template section builder is used to addtopics and the related text to include within a template. Subjectiveinformation routinely reviewed with the patient for a particularcomplaint or disease process should be included. Such topics may includeone of the HCFA recommended element names (including chronology, onset,description, intensity, exacerbation, etc.) or one of the user's ownchoosing. Related text can then be typed in the sentence as one mightnormally report the finding.

Within the sentence, text may be selected, options such as text entryfields or drop-down boxes can be specified, and appropriate responsesincluded. Other text options include patient specific demographicinformation or gender specific pronouns to default into the sentence.The HPI template section builder is used to define the elements of theHistory of Present Illness that may need to be addressed when a patientpresents with a specific complaint or group of complaints. The HPIselections will be unique to the template it is created within.

As shown in FIG. 18, the template builder provides a drop-down menu forthe topic name field. The user can select from the defined list or typea topic name that will display within the template builder and describethe information that the related sentence addresses. HCFA recommendedelements are denoted by a different color. Specific sentences areassociated with each topic name. As shown in FIG. 19, if the userselects the topic name Chronology, the sentence “The patient complainsof ______ for the last ______of ______.” The suggested sentences arepulled in from the HPI administration piece.

The user can attach control types to text within the sentence byhighlighting or selecting a phrase, as shown in FIG. 19. A list ofavailable control types is displayed for selection by the user. Controltypes include, for instance, Care Provider List, Date Stamp, Duration,Measurement, Make Input Box, Make Multiple Select, Make Select List,Number Selector and Demographic Information. The Care Provider Listattaches a list of care providers; Measurement is used to select anumber and unit of measure; Make Input Box enables the user to create apoint in the sentence where data can be typed; Make Multiple Selectallows the user to identify and add a list of multiple choices that willbe available in the sentence when using the template.

The Make Select List option creates a list of options that can beapplied to a selected text within the sentence. The user can branch thesentence to give more details about the sentence contents. For example,if the patient responds positively to the question “Have you ever hadthese symptoms before?” then the physician may follow up with questionssuch as “How long ago?” and “What treatments were used?” If the patientresponds negatively to the initial question, the physician does not needto ask the follow-up questions. The Demographic Information control typeattaches the text “age/race/sex” control to this point in the sentence.When the template is being used in the document builder, the patient'sage, race and sex will populate the field.

Other control types include He/She, Him/Her, Himself/Herself, andHis/Her. These control types are used to designate a point where thecorrect gender specific pronouns will default into the sentence.

The user can preview the selected choices, as they will be viewed in thetemplate, at any time during the building process. All body systems andassociated elements of exam may be available to all templates. A previewof the template is shown in FIG. 20, for both the Chief Complaint andHistory of Present Illness sections.

As shown in FIG. 21, the ROS template section builder displays a list ofbody systems the user can select to add to the template. Once thesystems are selected, the user will navigate to the next page and selectthe items associated with the body system that are regularly reviewedwith the patient. Users will ask the patient questions about the bodysystems, depending on the reason for visit.

For each of the body systems selected from the inventory, theexamination element is displayed, as shown in FIG. 22. Comprehensivesets of elements and modifiers have been included as system defaults foreach system to cover a general review of systems. Each user may buildthe elements into his templates according to practice needs. As eachsystem heading is selected by the user, multiple symptoms related tothat system are displayed. As shown in FIG. 22, the user can also definethe default settings for the symptom to appear neutral, negative orpositive. This allows the user to more quickly document the findings,eliminating clicks of the mouse (or taps with the stylus) during theencounter. The user can also define any modifiers that can be added tofurther detail the conditions.

The ROS administration section of the chart allows the user to specifywhich symptoms will display for each body system, and in which order. Itwill also allow the physician to set normal default text. The user maychoose to add additional symptoms. The ROS administration must be usedto perform additional actions that are not available from this page. Anysymptoms added to the ROS administration page will be available to alltemplates and not just the current template being edited. The optionsselected during the ROS building display with the associated defaultresponses for positives and pertinent negatives displayed.

FIG. 23 shows the PE administration of the template builder. The setupchosen by the user is applied to all document templates having a PEsection, such as Progress Notes, H&P Notes, etc. The PE administrationcan be accessed from the desktop or facesheet. The PE administrationenables the user to configure a page that is used as a worksheet orchecklist for the physician's physical examination of a patient.

Systems is a label for the systems that are displayed on theadministration page and are also used as a guideline or checklist forthe physician during examination of the patient. The categories aredisplayed in the following order by default (to correspond to the CMSdefault): Constitutional, Eyes, HENT, Neck, Chest, Cardiovascular,Breasts, Gastrointestinal, Genitourinary, Lymphatic, Musculoskeletal,Skin, Neurologic, and Psychiatric. Each category is a body system and istherefore a component of the physical exam. As each category is opened,there is a level of subcategories displayed beneath. Subcategories canbe created to greater and greater levels on the page. The system willsupport as many levels as the user wishes to create.

The findings content area displays the various systems available to theuser. In the example, the user has chosen Eyes, and that selection isdisplayed in the title or control bar. The system Eyes has four macros,namely Comprehensive Exam, Conjunctivae, Sclerae and Lids, which is alsolisted in tree format in the navigation sidebar. The user can use thenavigation sidebar to move between the various systems and locations,and can expand and collapse the systems and macros in the tree.

One or more findings are listed for each macro that is displayed. Theuser can add new macros and/or findings to the selected system by usingthe control buttons in the control bar. The user is then presented witha list of the current macros or findings, and can add, delete, reorderor edit any of the macros and findings.

The user selects those findings that the user would like displayed inthe progress note and template builder preview page. Unselected findingswill not show up in the progress note and template builder preview page.Once the user selects a finding, the user is presented with a list ofdefined values for the specified finding. The values are listed in theorder that they will be displayed in the template. The user can selectone or more of the displayed values to be the default value for thefinding, and can add, delete, reorder or edit any of the displayedvalues. The selected values will appear on the template when the userselects the finding during document building. The user can then selectthe values that are appropriate to be added to the document being built,or can add, delete or edit those values.

The user can also associate one or more modifiers to any of thefindings. The modifiers are listed according to categories, such asmeasurements, locations, descriptions. An example of a modifier would be“inches” for the finding “eyelid symmetry”, which would be displayed onthe template and allow the user to specify a measurement in inches to beassociated with that finding. The user can add, delete or edit thecategories and modifiers.

The systems are linked to E/M coding by the system. Because of this, thefindings of the physical exam which are selected from the default menuwill all be linked to E/M coding. The user/caregiver may add his/her ownfindings, which will also be linked to the E/M coding by virtue of theirbeing located in subcategories (folders) that are linked. The user mayalso link his added findings and subcategories to SNOMED CMV via theSNOMED selection tool, which is available on the page to allow the userto search the SNOMED database.

The next section in the template builder is Assessment. As shown inFIGS. 24 and 25, the Assessment template builder section allows the userto build a differential diagnosis list for the present template. Theuser selects a diagnosis from a previously built “favorite” diagnosislist or searches for diagnoses using the ICD-9 search tools.

FIG. 26 shows the Plan section building administration, which is used tocreate group-level and diagnosis-specific plans. The Plan sectionbuilding can be accessed from the Template administration page, and ispart of creating a Progress Note or H&P template. The group-level plan,shown as the Common Plan, is used to define a plan for the template,whereas the diagnosis-specific plans can be created that are specific toa clinician's diagnosis as selected from the differential diagnosis listin the present template.

There are preferably at least three parts to each plan, namely Orders,Medications and Instructions. In FIG. 27, the user has selected toconfigure the Orders, and a menu list is displayed having various PlanTypes and Categories. Plan Types include Labs, Procedures, Consults,Imaging, Immunization and Injections. In the example, the user hasselected the Plan Type of Labs, and the Categories for Labs is displayedas Panels, Chemistry, Endocrine, Hematology, Microbiology, Urinalysis,Fetal Test, and Surgical. The user can create new Plan Types.

Once the Plan Type is selected, the user can choose from amongst thepossible Categories, or can create a new Category. The user has selectedthe Category Endocrine, and the list of Labs for that Category aredisplayed for the user's selection.

As shown in FIG. 26, the user has selected two Panels and an Endocrinefrom the menu list. The selections are displayed on the Plan pagebeneath Orders for the Lab Plan Type.

The user can preview the entire template that he/she has created, ratherthan in separate sections. In the preview mode, the user is able to viewthe template sections as they will appear when creating a document usingthis template. The user can see items in each template section and mayadd omitted items or delete unnecessary items.

FIGS. 28 and 29 show an example of template preview. FIG. 28 shows thevarious sections of the template built by the user. At FIG. 29, the userclicks the “+” button beside the Review of Systems label and the ROSlist is displayed in the action bar. The user may then add or deletesystems in the ROS Template Section. However, in order to edit thesymptoms within each system, the user must return to the ROS templatebuilder section and/or the ROS Administration page.

FIG. 30 shows the preview for the Physical Examination section. The usercan either select the option “B” to preview a basic exam, or can selectoption “C” to preview a comprehensive exam. At FIG. 31, the user ispreviewing the Assessment section of the template. If the user selects adiagnosis from the Assessment (congestive heart failure in the example),the Orders, Medications and Instructions or Education pre-fill intotemplate sections, as shown in FIG. 32. The Orders Medications, andInstructions or Education are associated with the selected diagnosis.

Document Builder 44

The document builder 44 supports the creation and generation ofdocuments such as Progress Notes, which is implemented through the useof templates. A template is a pre-defined set of data options that isused to dynamically generate a document. Templates do not specify howsections are presented to the user, but rather the data that is utilizedat the time of documentation. A document may be created using notemplate, one template, or more than one template. For instance, the Flutemplate and the Cold template can be combined for a new visit documentwhere the patient presents with flu-like symptoms.

The document builder 44 includes features that assist the user inquickly building document text for each section of a document for thepatient chart. Multiple data capture formats are supported in thisfeature. Data options defined in a template may be used to furthersimplify creation of that section of a document. For example, a “normalsore throat” template may have been defined to automatically populatethe CC, HPI, ROS, PE, and A/P sections of the document with appropriatequestions and answers for a patient presenting with a sore throat.

The system has intuitive templates 42, 43 with easy-to-use point andclick data entry and optional keyboard use. There are multiple ways toenter information, from point-and-click using the templates, to drawingon the input device, taking digital photographs or video, dictation(voice recognition), audio, typing, and hand writing (handwritingrecognition). Information can be viewed as text, in table form, as aflow sheet, or as a graph. The user has a library of templates to choosefrom, with certain templates being for general use by nearly allclinicians, and other templates beings detailed to specialty clinicianssuch as dermatologists and urologists. In addition, the user can createtemplates from scratch, or by editing other templates.

The templates 42, 43 facilitate the entry of information into the systemin a manner that is easy to use, intuitive to the user and faster thanmaking paper entries. The templates 42, 43 help the user ensure that allnecessary information is entered so that documentation is complete andaccurate. The system provides for direct entry of documentation into thecomputer, eliminating the need to dictate, review and signtranscription. The templates 42, 43 allow the user to pull forward datafrom prior visits, so that the clinician can simply note changes sincethe last visit without re-recording information that was previouslycollected and has not changed.

The system primarily has three types of templates: history and physical(“H&P”)/progress notes, procedure notes, and consultation notes. Summarylists (such as medication, allergy and problem lists) are automaticallyupdated directly from progress note documentation. The templatesautomate the generation of documents for consultation correspondence,hospital admission, H&P (history and physical) documentation, procedurenotes, work and school excuses, and other standard communications.

In the exemplary embodiment of FIG. 7, a flu template 42 and coldtemplate 43 are shown. Each H&P/Progress Note template may include thefollowing sections: chief complaint (CC), history of personal illness(HPI), review of systems (ROS), physical examination (PE), Assessmentand Plan. The flu template 42 includes sections for chief complaint, HPIand ROS, and the cold template 43 has assessment, plan and ROS sections,which are defined in the respective sections of the template buildercomponent 41.

Each section of the templates 42, 43 permits the clinician to selectfrom among a list of default data options. For instance, the ROS optionsavailable to the clinician for the flu template 42 may include runnynose, sinus drip, sneezing, and difficulty breathing. The templatebuilding and document building are designed to track the manner in whicha clinician would typically record events at a patient encounter processon paper, from CC to HPI to ROS to PE to Assessment to Plan. However,the user can jump from one section to another and need not follow anyparticular order.

The templates are used to quickly generate documents. Once the clinicianhas completed the template 42, 43, the document builder 44 generates aprogress note that will be retained as the final document for thatpatient encounter. The document will have a main body section thatconsists of the sections from the templates 42, 43, as well as a sectionfor histories and habits to address patient history information such aspast medical history, specific condition history (e.g., cardiachistory), surgical history, medications, allergies, family medicalhistory, genetic screening, social history and problems. In the exampleof FIG. 7, the main body section of the document being generated for flutemplate 42 indicates the chief complaint, HPI, ROS and any other textentered by the clinician.

The document builder compiles the various sections into a document basedupon the clinical document architecture (CDA), as defined by HL-7(Health Level 7, a standards body). The document can be electronicallysigned. The document is created in XML format, and can be converted intoa modified XML format which is compliant with the HL-7 CDA standard byXSLT processing. Once the document is created, it is sorted according toits document type, and stored in a respective file system 45, 46, 47,where it resides in the patient chart. The documents may be sorted, forinstance, by document type (e.g, History & Physical, Progress Note,Procedure Note, etc.), document status (e.g., Authenticated or InProgress), creation date/time, or by the user who created the document.

Document Building—Progress Notes

The Progress Note is an example of a document that is created by thedocument builder 44 in accordance with a pre-defined template. TheProgress Note is the physician's primary note for a particular patientencounter, and is amendable and printable. The system extensively usesintuitive graphical user interface technologies and electronic drawingtools to ensure that an entire patient encounter can be documented byjust pointing and clicking through the patient record. However, thesystem also allows for keyboard entry as an alternative method to inputinformation. On average, a clinician can complete a Progress Note inabout 1-2 minutes or less. Once the Progress Note is completed andelectronically signed by the clinician, the note is saved and availablefor printing and future access.

A sample Progress Note template used to generate a Progress Notedocument is shown in FIG. 33. The user can select to complete a progressnote from the desktop, facesheet or document list. Once the user selectsto create a Progress Note, a blank progress note is displayed. The userthen determines if the visit displayed on the action bar is appropriate.If the user chooses to create a Progress Note without a visit link, theuser can select the default visit displayed (last visit is the default)or select a new one by clicking a link button which allows the user tosearch for a visit date.

Once the visit date is selected, the user selects a template to use froma list of template fields that are displayed on the action bar. Severaltemplate fields can be provided to assist the user in finding thedesired template, such as either a physician's template field or anurse's template field. Upon clicking on the template field, a drop-downmenu displays the user's custom templates that were earlier created, aswell as any standard pre-defined system templates designed for thattemplate field.

In FIG. 33, the user has selected to work with the template “CABGPre-Surgical Office Visit” from the list of templates in the drop-downmenu. Multiple templates may also be selected by the user by clickinganother template from the list. The user can work on different templatesfor multiple patients, and a tab is shown at the bottom of the screenfor each patient that the user is working on to enable the user toquickly switch between templates and/or patients. In addition, the nameof the selected template “CABG Pre-Surgical Office Visit”, is displayedabove the template field and the template pre-fills into the ProgressNote.

The system pre-fills all of the selected items for the Template, whichwere defined during the Template administration, and displays thedefined template sections. Typically, the template has the followingsections: Chief Complaint, History of Present Illness, Review ofSystems, Physical Examination, Assessment, and Plan.

To create the completed Progress Note, the user edits the Progress Noteby clicking desired findings from the patient encounter. The ChiefComplaint document section builder of the template builder 48 enablesthe user to select the chief complaint that most closely relates to thepatient's subjective description about the problem that has brought thepatient to see the physician. A list of possible chief complaints, suchas “I am tired” or “My chest hurts”, that were associated with thetemplate is displayed for the user to select to add to the document.

The HPI document section builder of the template builder 48 enables theuser to enter information into the HPI section. Selecting the History ofPresent Illness header on the document will populate the field with thedocument view of selected descriptions associated with the template.Information can be selected in the document builder in accordance withthe manner set up when the template was constructed. Information can beentered by the user in the form of a list, date stamp, input box,multiple select (select multiple choices from a predefined list ofmultiple choices), and demographic information. An example of a list isshown in FIG. 33, where the user's selection of “severe” has beenentered into the document. Certain text may designate where the correctgender specific pronouns of he/she, himself/herself, his/her, him/herwill default into the sentence.

FIG. 34 shows further editing in the ROS document section beingperformed by the use of checkboxes. The ROS document section is aninventory of body systems obtained through a series of questions seekingto identify signs and/or symptoms which the patient may be experiencingor has experienced. The ROS document section is a vital part of thepatient encounter. The ROS can be accessed from the patient chart in thetriage note or from the Progress Note. When ROS is in a document, ROSwill appear on the menu bar in the Template Administration page forselection by the user.

The user can complete the ROS document section based on informationgathered during the patient's office visit, as the user asks the patientquestions concerning particular body organs and/or regions. The reviewis documented in a systematic manner and certain sections can pre-fillfrom registration or triage to the ROS document section of thephysician's Progress Note. The user may examine all systems or one ormore systems, and may choose to not include the remaining systems,depending on the patient's reason for visit, physical appearance, etc.When some systems are not included in the ROS document section, thosesystems will not be shown in the narrative summary of the ROS. If allsymptoms are neutral, the system is not included. If the system haseither a negative or positive symptom, the system is included.

As each system heading of the ROS document section is selected by theuser, multiple symptoms related to that system are displayed. Thedefault settings for each symptom will be “neutral”. The user may clickon the checkbox next to the symptom once to change the status to“negative” (−); one click on the checkbox again changes the status to“positive” (+). In FIG. 34, the user has selected the systems,Constitutional and Cardiovascular, and the respective symptoms aredisplayed, such as absence of pain, cardiac murmur and chest pain. Theuser has selected the symptom “chest pain” as a positive status(indicating that the patient is experiencing chest pain). The negativestatus indicates that the patient denies a symptom, such as chest pain.

To enter more details about the positive status of a symptom, the usercan click on the actual word (name of the symptom). Clicking on the wordwill cause the radio button to change to “positive” and a pop-up detailsbox will appear, as shown in FIG. 34. The details box allows the user toselect more detailed information, such as duration, severity, location,alleviating factors, etc. The descriptive terms have been defined by theuser in the ROS administration piece. After entering a furtherdescription of the positive symptom, the descriptor appears next to thesymptom name. Categories of body systems and the symptoms under eachbody system may be edited, added or deleted in the ROS administrationpiece.

As shown in FIG. 35, the Physical Exam document section builder of thetemplate builder 48 enables the user to complete a physical exam of thepatient. The user selects the PE document section associated with apre-built template or by choosing the system and related componentsindependent of any template and enabling the care giver to create adocument describing the examination from the physician.

When the basic exam or “B” button is clicked, all systems selected forthe template are pre-selected for the basic exam. When the comprehensivephysical exam or “C” button is clicked, all systems selected for thetemplate are pre-selected for the comprehensive exam. If nothing isselected under “Full Exam”, then the user may select B or C for each ofthe systems, as shown in FIG. 35 for Cardiovascular. Only the systemsselected are displayed. With each system, the user may select basicexam, comprehensive exam, or both. If nothing is selected, then thedefault that is displayed is both exams—the list of findingsspecifically included in the template being used for this document. Theuser may select which one of the two types of exams he wishes todocument in the patient record.

The user can select findings for any of the terms in the Physical Examdocument section. In the example of FIG. 35, the PE document sectionCardiovascular has a subcategory to Auscultation called “Rate”,“Rhythm”, and “S1”, which are displayed when the user selectsAuscultation. By hovering over the text, a pop up box is displayed withmore detailed information about selected findings. Here, the user clicks“S1” and the cascading menu for S1 displays. The user may select fromthis menu. In this case, whatever finding the user selects will be addedto the Auscultation portion of the physical exam, and the finding isdisplayed.

Alternatively, the PE builder can be implemented in a manner similar tothat described with respect to FIG. 23, which is for templateadministration. That is, a navigation sidebar can be provided that listsall the systems, and the systems and finding can be displayed withselection boxes. Values and modifiers can be associated with eachfinding. At any time during the document building process, the user canpreview the document by selecting Preview on the navigation bar at thetop of the page. All sections of the customized template are displayedon the preview page, and can be edited by the user.

In FIG. 36, the Assessment and Plan document sections are displayed andthe selections are bolded. Upon the user's selection of a diagnosis fromthe Assessment section, the orders, medications, and instructions of theplan section are automatically completed, as shown. The user may utilizeany of the note options. The Assessment document section containsdiagnoses (with related ICD-9 coding) chosen by the user in theAssessment & Plan template section builder. The Progress Note is createdand the section of that document called “Assessment” displays thepre-selected diagnosis options from which the user may select thedesired diagnosis or multiple diagnoses. The user selects the diagnosisor multiple diagnoses by clicking on the checkbox of the desireddiagnosis.

Checkboxes can also be provided to allow a clinician to mark an item as“rule out” instead of a diagnosis. That is used when tests are orderedto rule out a certain diagnosis, so the code for that item should not beused to bill the encounter, as it is not really a diagnosis. Theselected diagnosis and the associated ICD-9 code becomes bolded, asshown. Once the Progress Note is documented, it is displayed to the userin completed form.

Following a patient encounter, the clinician will usually have orders,prescriptions, and instructions for the patient. The clinician is ableto document the “plan” for the patient in a section of a document whichbecomes part of the patient's chart, such as in the Progress Notedocument. These plan items can be associated with each particulardiagnosis. For example, a patient who is having chest pain willtypically require at least a chest x-ray, an EKG, a prescription fornitroglycerin, and a follow-up visit.

In the Order section of the document, the physician lists the ordersassociated with the progress note and/or office visit. The orders arelinked to CPT coding. They may be the CPT codes as well as user-createdorders that are linked to the CPT codes. The Orders associated with thediagnoses for this particular template are pre-filled into the ProgressNote under the “Orders” section, as shown above. A checkbox to the leftof each Order is present to enable the physician to choose theparticular Orders for this patient. The user selects the desired Orderfor the patient by checking the checkbox. The selected item is bolded,and the CPT coding is placed to the right.

At this point, the document is complete and the user's selections aredisplayed as a final document, as shown in FIGS. 37 and 38. Each sectionis displayed, even if no entries were made to that section. However,areas that were not examined or inquired into by the clinician are notdisplayed, so that for instance Constitutional is not displayed underthe PE section. The Progress Note, if saved or authenticated (saved &signed), is then displayed in the document list of the patient's EMRchart, FIG. 39. It may be closed, opened, or amended if saved orauthenticated. If not saved, it can be deleted. The Progress Note issaved and displayed on the document list, “Chart Documentation.”

Other documents can be generated by the document builder, and othermedical history information can be included in a progress note asseparate sections, including Past Medical History (PMH), Past SurgicalHistory, Social History, and Family Medical History. These documentsgenerally enable the clinician to gather information about the medical,social and family history of a patient. As an example for PMH, forinstance, illnesses can be organized under the categories of the bodysystems they affect. The list of illnesses are pre-selected by theclinician. When specific illnesses are selected, the user may enterdates of onset and any notes concerning the situation. This function canbe accessed from the other areas in the system, such as the face sheet.

Another type of document that is generated from the document builder isthe H&P Note. An example of the PE section of an H&P Note is shown, forinstance, in FIG. 40. Here, the system macros are listed along the leftside of the page, such as Constitutional, Eyes, HENT, Neck and Chest.The user selects a system in order to display the findings and place thefindings in edit mode. The user can choose option “T” to only edit thefindings that were defined during the template administration, option“C” to edit all findings in the location, or option “F” to edit allfindings for one or more macros. In the example, the user has selectedthe system Eyes, and the options All; Cond, Sclera, Lids; Pupils andIrises; and Funduscopic Exam are displayed in the order of location ofthe systems.

The findings are displayed adjacent the location options. In theexample, the findings for the system Eyes is displayed in edit mode.When a user selects a finding name, a list of modifiers is presented forfurther selection by the user. For instance, the modifier can indicatethe severity of the finding as being “severe”, “moderate” or “mild”. Theuser can select the appropriate modifier, which then becomes associatedwith the finding in the final H&P Note, whereas the findings for thesystem HENT are displayed with their default values and modifiers whichhave been selected for this system in the PE template builder upon whichthis note is based.

A drawing can also be incorporated into the H&P note or progress note.The drawing allows the user to select anatomical images from a library,draw on them and embed them into documents and notes to better documentmedical information that might be difficult to communicate with wordsalone. For instance, the physician can select an image of a patient'sabdomen and draw the location of previous surgical scars, changes indiscoloration or area of infection between visits. As the H&P orprogress note is being created, the user has the option of selecting toinclude a drawing. The user then selects the desired image from thelibrary of images. Preferably, this is achieved by displaying an imageof a full human body, and allowing the user to focus in on a specificarea. Once the desired image is displayed, the user then draws thedesired shape and color to add to that image.

Order Management

An additional system feature includes clinical alerts, reminders andtracking. These features allow clinicians to more effectively servetheir patients. Once a patient leaves the office, the system tracks thestatus of requested consultations and tests, and provides respectivealerts and reminders to the respective users. The alerts can berequested by the clinician or based on standard health maintenanceprotocols. It automates the process of reviewing and tracking incomingand pending order results so that fulfillment is documented and failureto fulfill is investigated and remedied.

Clinicians can also define alerts, reminders and recommendations fortreatment based on the user's preferred treatment algorithms or oninsurance rules for reimbursement. Users can also define links tointernal and external resources for clinician reference and patienteducation.

The system also has automated prescription writing, and interactionreference access. Electronic transmission capability to fulfillmentresource and refill management is automated, thereby reducingprescription and refill processing. The system automates fulfillment oforders by real-time transfer of instructions directly from an encounterdocumentation template to the fulfillment source, without the need toduplicate the instructions in an intervening document or data entryprocess.

For example, prescriptions are automatically electronically transmitteddirectly from the encounter documentation to the participating pharmacy,lab orders are automatically transmitted directly to the participatinglab with supporting diagnoses and prior approval included, diagnoses andcoding are automatically transferred from the encounter documentation tothe billing module, and follow-up appointment requests are directlytransferred from the encounter documentation to the scheduling module(i.e., part of the practice management module).

Prescription refills are also automated, so that the clinician need onlymake a single selection for refills requiring no changes. The clinicianneed not write a new prescription for the refill, the refill isautomatically documented in the patient's chart, and the instructionsare electronically transmitted to the pharmacy.

Another feature of the system is order placement which integrates withbilling processes to reduce charge entry efforts and ensure thatthird-party reimbursement requirements are met.

Messaging

The system supports communication between the clinician and other staffmembers from any point in the facility at any time. Messaging isimplemented by a messaging component 22 of the framework module 20, thatcreates, stores and retrieves intra-office communication. Messages canalso be generated by the system to indicate situations where action isrequired. Messages are automatically added to the patient chart, whenthe user chooses to “attach” a patient to the message.

The messaging module gives near real time updates that new messages havearrived. The customer workstation 12 is in contact with the mainservices server 10 every few seconds to check if new messages havearrived. A service is used, as opposed to a web page, to keep theconstant pinging from affecting the application. The messaging modulemaintains an icon to the desktop that indicates that a new message hasarrived. The system indicates to the user that a new message hasarrived, which the user can then retrieve.

When composing a message, once a Patient is selected, the correspondingPatient Frame overlays in the body of the Message. If there is aphotograph of the patient displayed in the Patient Frame, the photo willalso be displayed in the Message. If there is a Patient Name in thePatient field, the Message will be associated with that Patient. AllMessages composed and sent by the user are audit logged, indicating thatthe action was a sent message, the patient ID, the sender and therecipient, and the time.

The messaging system is provided with predefined response templates forcommon requests and routine calls and questions. Responses generate anote in the patient's chart.

Patient Access

The system provides secured and structured two-way communication betweenthe patient and the clinician. The patient can submit post-treatmentoutcome results and status to the clinician in a predefined template.That allows the clinician to analyze the effectiveness of the treatmentprovided without the burden of reading free-text email. The increasedpatient interaction strengthens the clinician-patient relationship andincreases the efficiency in scheduling appointments, registration, theinterview process and requesting prescription refills. That is not onlymore convenient for the patient, but allows the clinician practice toshift a great deal of data entry from their clerical staff to thepatient.

Patients access the system through a centralized web portal, such astheir clinician's website. The web portal allows the patient to performlimited functions with respect to appointment scheduling, patientinterviews, prescription refill requests, personal health record access,appointment follow-up information and electronic consults. Patients canchoose to be reminded of appointments electronically at variousintervals before visits. Data from paper records can also be moved tothe personal health record (PHR). A PHR allows a patient to track visitsto a clinician, medications, in-home observations of blood sugar, vitalsigns, etc.

Audit Logging and Security

Audit logging is performed throughout the system to assist systemadministrators in enforcing practice policies and compliance withregulations. Security options include username and password and/orbiometric identification for access control. The username allowsrole-based and/or user-based control of permission to use various systemfunctions.

Overview of Features

The system is designed to be intuitive to the user and provide a secureenvironment that can be accessed at the clinician's office or at aremote site. The system also interfaces to email and the clinician'swebsite, and provides support for phone messaging, patient educationmaterials, website, direct patient data entry via the web, email, andROI studies.

The system eliminates the need for paper charts, thereby reducing theamount of office space allocated to storing patient records, andallowing electronic transfer of information between practices. Allincoming paper documents and existing paper patient files, can bescanned or otherwise entered into the system and the paper fileseliminated. The patient's EMR can be accessed at any time and from anylocation, thereby eliminating manual chart pulls and misplaced paperfiles. The number of chart pulls is reduced by about 50% within sixmonths of implementing the present invention, and about 85% at twelvemonths.

Once the system is fully implemented, transcription costs could beeliminated, malpractice premiums could be reduced by about 3-5% frominsurance companies that offer physicians who use an EMR a discount dueto the increased detail of documentation with an EMR as opposed todictation or handwriting, and staff savings of about 15%. Perhaps mostimportantly, clinician productivity gain increases by about 20% afteronly twelve months, resulting in a savings of about $7,000-15,000 perclinician each year.

The information provides rapid and concise malpractice proof to help theuser defend against malpractice claims and HCFA audits. The system alsooffers the clinician prescription assistance with brand name and genericpricing and dosage, national drug codes, medication lists, allergycross-checks (drug-drug, drug-food, drug-disease interactions), and sideaffects. The entry of charges is automated and the resultingdocumentation is checked for compliance with billing and claims filings.

Although the preferred embodiment of the invention is for use at aclinician's practice, the system can be implemented at the office of anyservice professional. The system is configurable at the user andpractice levels, so that a practice can assign specific duties andresponsibilities to employees to maximize overall office productivitywithout restrictions imposed by existing practice management and EMRsystems.

The foregoing description and drawings should be considered asillustrative only of the principles of the invention. The invention isnot intended to be limited by the preferred embodiment. Numerousapplications of the invention will readily occur to those skilled in theart. Therefore, it is not desired to limit the invention to the specificexamples disclosed or the exact construction and operation shown anddescribed. Rather, all suitable modifications and equivalents may beresorted to, falling within the scope of the invention.

1-62. (canceled)
 63. An integrated medical software system withlocation-driven bill coding, the system comprising: an informationsoftware component executed by a processor of the system toautomatically retrieve payment method data and demographic data for apatient and location data for a healthcare provider; a clinical softwarecomponent executed by the processor of the system to capture at leastone of a diagnosis code, a procedure code, and an evaluation andmanagement (E&M) code as at least one of a clinician and a staff memberat the healthcare provider inputs clinical data for the patient into anelectronic document during an encounter with the patient; a mappingsoftware component executed by the processor of the system toautomatically associate a billing code with the at least one of adiagnosis code, a procedure code, and an E&M code and assigns a servicecost to the billing code based on a pre-defined fee schedule, saidpre-defined fee schedule being automatically chosen based on thelocation data for the healthcare provider; and a service detail entrysoftware component executed by the processor of the system to use thepayment method data and the demographic data for the patient and theservice cost to automatically generate at least one of a bill, a claim,and a statement for the patient.
 64. The integrated software system ofclaim 63, further comprising an administrative software componentexecuted by the processor of the system to provide a plurality ofpre-defined fee schedules from which the mapping software componentchooses said pre-defined fee schedule based on the location data of thehealthcare provider; and allowed amount data corresponding to a payoridentified by the payment method data for the patient, wherein theallowed amount data and the chosen per-defined fee schedule is used bythe service detail entry component to determine an allowed service costthat the payor will pay for the patient.
 65. The integrated softwaresystem of claim 64, wherein the service detail entry software componentautomatically recalculates the allowed service cost when at least one ofthe payor identified by the payment method data of the patient changesand the allowed amount data corresponding to the payor changes.
 66. Theintegrated software system of claim 63, further comprising anadministrative software component executed by the processor of thesystem to provide functionality for viewing at least one of a bill, aclaim, and a statement for the patient generated at multiple healthcareproviders based on a common tax identifier shared by those healthcareproviders.
 67. The integrated software system of claim 63, furthercomprising: a database that stores scheduling data, financial data, thedemographic data, and the clinical data for the patient in a normalizeddata format; a scheduling software module executed by the processor ofthe system to capture scheduling data in the normalized data format andto schedule the patient and at least one of a clinician, a staff member,and equipment at a healthcare provider using the scheduling data and thedemographic data, said scheduling data including the location data forthe healthcare provider; an account management software module executedby the processor of the system to capture financial data for the patientin the normalized data format, said account management software moduleincluding the information software component, the mapping softwarecomponent, and the service detail entry software component, and saidfinancial data including the payment method data for the patient and theservice cost; a clinical software module executed by the processor ofthe system to create the electronic document and to capture the clinicaldata in the normalized data format, said clinical module including theclinical component; and a framework software module that is integratedwith the scheduling software module, the account management softwaremodule, and the clinical module using a common architecture and that isexecuted by the processor of the system to support an exchange of thescheduling data, the financial data, the demographic data, and theclinical data between those software modules and with the database inthe normalized data format.
 68. The integrated software system of claim67, further comprising: a registration software module executed by theprocessor of the system to capture the demographic data for the patient,said demographic data including at least one of a name, a digitalphotograph, an address, a date of birth, an age, a social securitynumber, and a sex of the patient, wherein the information softwarecomponent automatically retrieves the demographic data for the patientfrom the registration software module.
 69. The integrated softwaresystem of claim 67, wherein the information software componentautomatically retrieves the location data for the healthcare providerfrom the scheduling software module.
 70. The integrated software systemof claim 63, wherein the information software component alsoautomatically retrieves date of service data and healthcare provideridentification data for the patient and the healthcare provider; and theservice detail entry software component also uses the date of serviceinformation and the healthcare provider identification information toautomatically generate the at least one of a bill, a claim, and astatement.
 71. The integrated software system of claim 63, wherein theservice detail entry software component uses the payment method data andthe demographic data for the patient and the service cost toautomatically generate an electronic insurance claim and communicateswith an automated claims clearinghouse to electronically process theinsurance claim.
 72. The integrated software system of claim 71, whereinthe insurance claim is generated by automatically populating eachrequired field in an institutional or professional claim form; and theinstitutional or professional claim form is communicated to theautomated claim clearinghouse in the ANSI X12 837 data format.
 73. Amethod for providing location-driven bill coding with an integratedmedical software system, said method being embodied on aprocessor-executable medium and said integrated medical software systemhaving a processor that executes the method to perform the steps of:using an information software component to automatically retrievepayment method data and demographic data for a patient and location datafor a healthcare provider; using a clinical software component tocapture at least one of a diagnosis code, a procedure code, and anevaluation and management (E&M) code as at least one of a clinician anda staff member at the healthcare provider inputs clinical data for thepatient into the an electronic document during an encounter with thepatient; using a mapping software component to automatically associate abilling code with the at least one of a pathology code, a proceduralcode, and an E&M code and to assign a service cost to the billing codebased on a pre-defined fee schedule, said pre-defined fee schedule beingautomatically chosen based on the location data for the healthcareprovider; and using a service detail entry software component toautomatically generate at least one of a bill, a claim, and a statementfor the patient with the payment method data and the demographic datafor the patient and the service cost.
 74. The method of claim 73,further comprising the steps of: providing an administrative softwarecomponent that includes a plurality of pre-defined fee schedules fromwhich the mapping software component chooses said pre-defined feeschedule based on the location data of the healthcare provider, andallowed amount data corresponding to a payor identified by the paymentmethod data for the patient; and using the service detail entry softwarecomponent to determine an allowed service cost that the payor will payfor the patient based on the chosen pre-defined fee schedule and theallowed amount data.
 75. The method of claim 74, further comprising thestep of said service detail entry software component automaticallyrecalculating the allowed service cost when at least one of the payoridentified by the payment method data of the patient and the allowedamount data corresponding to the payor changes.
 76. The method of claim73, further comprising the step of using an administrative softwarecomponent to view at least one of a bill, a claim, and a statement forthe patient generated at multiple healthcare providers based on a commontax identifier shared by those healthcare providers.
 77. The method ofclaim 73, further comprising the steps of: using a scheduling softwaremodule to capture scheduling data in a normalized data format and toschedule the patient and at least one of a clinician, a staff member,and equipment at a healthcare provider using the scheduling data and thedemographic data, said scheduling data including the location data forthe healthcare provider; using an account management software module tocapture financial data for the patient in the normalized data format,said account management software module including the informationsoftware component, the mapping software component, and the servicedetail entry software component, and said financial data including thepayment method data for the patient and the service cost; using aclinical software module to create the electronic document, saidclinical module including the clinical component; and using a databaseto store the scheduling data, the financial data, the demographic data,and the clinical data for the patient in the normalized data format,wherein a framework software module is integrated with the schedulingsoftware module, the account management software module, and theclinical software module using a common architecture and that supportsan exchange of the scheduling data, the financial data, the demographicdata, and the clinical data between those software modules and with thedatabase in the normalized data format.
 78. The method of claim 77,further comprising the step of: using a registration software module tocapture the demographic data for the patient, said demographic dataincluding at least one of a name, a digital photograph, an address, adate of birth, an age, a social security number, and a sex of thepatient, wherein the information software component automaticallyretrieves the demographic data for the patient from the registrationsoftware module.
 79. The method of claim 77, wherein the informationsoftware component automatically retrieves the location data for thehealthcare provider from the scheduling software module.
 80. The methodof claim 73, wherein the information software component alsoautomatically retrieves date of service data and healthcare provideridentification data for the patient and the healthcare provider; and theservice detail entry software component also uses the date of serviceinformation and the healthcare provider identification information toautomatically generate the at least one of a bill, a claim, and astatement.
 81. The method of claim 73, wherein the service detail entrysoftware component uses the payment method data and the demographic datafor the patient and the service cost to automatically generate anelectronic insurance claim, and communicates with an automated claimsclearinghouse to electronically process the insurance claim.
 82. Themethod of claim 81, wherein the insurance claim is generated byautomatically populating each required field in an institutional orprofessional claim form; and the institutional or professional claimform is communicated to the automated claim clearinghouse in the ANSIX12 837 data format.